跳到主要内容

回放测试

流量录制回放是通过录制生产环境的高保真数据,并快速地在测试环境中进行回放比对接口返回值和中间链路的验证,以减少繁杂的回归测试、用例维护的重复性劳动,提升回归测试效率。

提示

不建议在生产环境回放,一般来说生产环境只录制流量,回放在测试环境或本地操作。

  1. 请先确认生产环境中用于录制的应用在配置 AREX Agent 后是否有流量请求,如果没有,则录制内容为空,无法进行回放。
  2. 测试环境中的被测应用也需要搭载 Agent,才能进行回放,回放过程对主接口将产生真实调用,而对外部第三方依赖(如数据库、Redis 等)则不会产生真实的调用,如果子调用入参与录制子调用的入参相同,则直接返回录制的数据。

查看应用

应用注册完成后,通过浏览器访问 AREX 前端页面,点击 Replay,即可在左侧菜单栏中看到已配置好的被测应用。

录制应用列表

默认情况下,应用在搭载 Agent 后,AREX 将自动开启录制该应用所有时间段内的线上真实请求流量。你也可以通过录制回放设置,根据自己的需要设定录制任务。

查看录制详情

当应用产生请求流量并被录制后,可以在回放任务列表上方查看录制详情。(此处显示的是基于当天往前的 4 天内录制到的所有用例)

流量录制详情

提示

目前数据库中默认只保存 4 天内的录制用例,超期后用例会被自动删除。如果需要长时间保留,可以在 docker-compose.yml 文件的 arex-storage-service 配置项中增加一条:

arex-storage-service:
image: arexadmin01/arex-storage-serive:$AREX_VERSION
container_name: arex-storage
restart: always
ports:
- '8093:8080'
volumes:
- ./arex-logs/arex-storage:/usr/local/tomcat/logs
environment:
- TZ=Asia/Shanghai
- JAVA_OPTS=-Darex.storage.mongo.host=mongodb://arex:iLoveArex@mongodb:27017/arex_storage_db
-Darex.storage.cache.url=redis://redis:6379/
-Darex.report.service.api=http://arex-report-service:8080
-Darex.storage.defaultExpirationDuration=1000000000
depends_on:
- mongodb
- redis

仅对修改配置并重启 AREX 之后录制的用例生效。

如下列出了录制到的所有接口,展开接口,下方是该接口所录制到的所有用例。

流量录制详情

点击某条用例,查看该条用例录制详情,左侧为录制过程中一些动态类及外部调用的第三方依赖(比如数据库等)的请求内容,以及主接口的请求。右侧为对应的响应体:

用例录制详情

部分录制的请求体/响应体是经过 base64 压缩的格式,需要自行解压查看。

开始回放

应用录制并设置完成后,可以进行回放操作。

提示
  1. 请先确认生产环境中用于录制的应用在配置 AREX Agent 后是否有流量请求,如果没有,则录制内容为空,无法进行回放。
  2. 测试环境中的被测应用也需要搭载 Agent,才能进行回放,否则将对外部依赖(如数据库、Redis 等)产生真实调用,产生脏数据。

点击需要进行回放测试的应用,进入回放测试页面。点击右上角 Start replay,即可进行回放。

流量回放页面

在跳转出的窗口中依次填入本地/测试环境中需要进行回放测试的端口地址(Target Host),即搭载了 Agent 的机器/被测机器的端口地址。

选择回放用例范围(Case range),对该日期区间内录制到的线上请求进行回放。

录制应用列表
提示

完整的 目标回放地址(Target Host) 应该是协议+域名+端口号(默认的 80 端口也需要手动输入),如下所示:

Target Host
  • 报告名(Name):自定义报告名称,默认命名规则是 <应用名+创建时间>
  • 回放路径(Paths):中可以选择本次测试中需要进行回放的路径,如没有设定,则默认回放所有路径下的用例。
  • 最大回放用例数(Case Count Limit):设定单个接口最大回放用例数,默认单个接口单次回放最大用例上限是 1000 个/接口。
  • Webhook:用于创建定时回放任务,参考>>定时回放

回放报告

回放报告

回放任务进行时,可以点击报告右上方的 Terminate 中断回放。

回放完成后,点击回放记录,可以查看详细的回放报告。

详细说明如下:

  • Terminate:中断该回放报告。Delete:删除该回放报告。点击 Rerun 可以重新进行回放。

  • Execution Logs:查看回放日志。

    回放报告

  • Pass Rate:回放用例测试通过率。(录制回放返回结果无差异视为通过)

  • API Pass Rate:接口测试通过率。

  • API:录制及回放中访问的所有接口列表。

  • State:接口测试状态,

    • running 表示正在运行中。
    • done 表示回放完成。
    • interrupted 表示回放中断,将光标移动至 interrupted,会具体显示中断原因,排查问题后可点击 Rerun 按钮重新运行测试。

回放中断

  • Time consumed(s):该接口回放测试的执行时间,单位为“s”。

  • Total Cases:该接口下测试用例的个数。

  • Passed、Failed、Invalid、Blocked:分表表示回放通过、失败、无效、中断的测试用例个数。

分析报文差异

接口用例中出现 Failed 说明回放与录制返回报文出现差异,点击右侧的 DiffScenes,查看差异。

录制应用列表

在实际使用过程中,对于一个复杂的线上应用,业务场景复杂,录制及回放的用例数量巨大,大大增加了排查问题的难度。

为了减轻使用者分析差异时的工作量,AREX 对存在相同差异的场景和差异点进行了聚合处理。

差异场景聚合逻辑

在进行流量回放测试时,针对可能出现的用例数量较大的情况,AREX 会通过一些聚合的操作,将相似的用例进行合并,以减少差异点的数量,便于用户对数据进行分析。如下图所示,聚合相似差异场景后,每个差异场景下仅选取一条用例作为展示。

在 AREX 中,一个用例通常由多个步骤组成,每个步骤包含了一个请求和一个响应。请求可以是主入口,也可以是外部调用(包括 DB、Redis 等)。在每个步骤中,都会记录请求的参数和响应结果等信息,用于后续的对比。如果录制与回放时的主入口响应,以及外部依赖的请求均无差异,则视为该用例回放通过。

这里的主入口和外部调用我们称之为 Mock 的类型。

Mock 差异类型

每个 Mock 类型的对比差异类型会被分为三种情况:

  • new call:这种差异类型表示该主入口或外部调用的 Mock 在录制时不存在,但在回放时存在,即新增了调用,通常是因为有新功能的迭代。
  • call missing:表示在录制时存在,但在回放时缺失了调用,通常是因为项目进行了优化,移除了某些不必要的调用关系。
  • value diff:表示在录制和回放时都存在,但在对比过程中某些节点有差异。后续章节中会具体介绍如何分析这些差异。

报文差异

差异用例场景聚合是为了将具有相同 Mock 类型和差异类型的用例聚合在一起形成一个场景,从而帮助用户更快速地了解整个场景中的用例情况,减少用户需要分析的用例数量,提高分析用例的效率。

首先,根据 Mock 的类型和差异类型的组合,AREX 会生成一个唯一的键,将所有用例分类聚合到这些键中,形成一个大分类。如上图中标注的 ①大分类

其次,每个大分类中的用例都会再根据具体的 Mock 和差异类型的排列生成一个子唯一键,进一步对用例进行分类。这样做的目的是为了更加细致地分类,以便更快速地分析差异用例, 具体可见上图中 ②小分类 的示例。每个小分类中有多少个用例数量会标记在该分类的最前面。

差异点聚合逻辑

在每个差异场景中,AREX 对相似的差异节点也进行了聚合展示。

在某些大报文的场景下,有些大数组中的差异点会非常多,一方面不利于前端展示,另一方面增加了使用者分析差异点的复杂度。

为了解决这个问题,AREX 将差异点按照模糊路径进行聚合。这里的模糊路径指的是不带数组下标的 JSON 节点路径。例如,一个 JSON 对象中有一个名为 “items” 的数组,数组中有多个元素 “items[0]”、“items[1]”、“items[2]” 等。在模糊路径中,这些路径会被合并为 “items”,从而实现聚合。

报文差异

差异点差异类型

  • Additional node:录制或回放后的返回报文中多出的节点。如有,差异点会在报文中以橙色高亮显示。

  • Difference node:录制及回放后的返回报文中不同的节点。如有,差异点会在报文中以蓝色高亮显示。

定时回放

可以参考以下步骤设立定时回放任务。

  1. 在回放界面上,点击创建回放,并填入目标服务的主机地址。然后会自动生成一个用于创建回放的接口调用链接(HTTP GET请求)。Case 的时间范围是从调用时间点开始往前的 24 小时。

报文差异

  1. 获取到创建回放的调用链接后,需要一个触发创建的介质:
  • 以 Linux 自带的 Crontab 工具为例

    1. 创建一个名为 "routine" 的文件,写入 0 5 * * * /usr/bin/curl [第一步中复制的创建地址](其中"0 5 * * *"是标准 Linux cron 表达式,表示每天的 5 点执行一次)

    2. 使用命令 crontab routine 加载上一步中配置的定时任务

    3. 使用命令 crontab -l 查看是否成功写入定时任务

  • 以 GitLab CI/CD 为例

    1. 建立一个类似的流水线(pipeline)

    pipeline

    1. 在 ArexTest Job 脚本中使用 curl 调用 1 中复制的链接

    2. 在仓库-> CI/CD -> Schedules 中创建定时任务来执行流水线

    pipeline

回放结果回调使用指南

回放结果回调是指在回放计划完成后,系统会通过调用用户自行配置的回调函数接口,将回放计划的相关信息以 POST 方式传递给用户。用户可以根据这些信息进行相应的处理,如监控和报警、统计和分析、自动化流程触发等。

配置

在系统设置中配置 ReplayCallbackUrl,当回放计划完成时,系统会以 POST 方式调用该 URL:

pipeline

实现

为了实现这个功能,需要用户自己实现一个回调函数接口,入参如下:

public class CallbackInformRequestType {

private String appId; // 应用ID
private String appName; // 应用名称
private String planName; // 计划名称
private Integer status; // 回放状态
private Integer totalCaseCount; // 总用例数
private Integer successCaseCount; // 成功用例数
private Integer failCaseCount; // 失败用例数
private Integer errorCaseCount; // 错误用例数
private Integer waitCaseCount; // 等待用例数
private Double passRate; // 通过率
private Long elapsedMillSeconds; // 耗时(毫秒)
private String creator; // 创建者
}